Resource request and transfer in a multi-node distributed system

ABSTRACT

Selective resource migration is disclosed. A computer system includes physical memory and a plurality of physical processors. Each of the processors has one or more cores and each core instantiates one or more virtual processors that executes program code. Each core is configured to invoke a hyper-kernel on its hosting physical processor when the core cannot access a portion of the physical memory needed by the core. The hyper-kernel selectively moves the needed memory closer to a location accessible by the physical processor or remaps the virtual processor to another core.

CROSS REFERENCE TO OTHER APPLICATIONS

This application is a continuation of co-pending U.S. patent applicationSer. No. 13/830,094, entitled SELECTIVE RESOURCE MIGRATION filed Mar.14, 2013 which is incorporated herein by reference for all purposes,which claims priority to U.S. Provisional Patent Application No.61/692,648 entitled HIERARCHICAL DYNAMIC SCHEDULING filed Aug. 23, 2012which is incorporated herein by reference for all purposes.

BACKGROUND OF THE INVENTION

Software applications are increasingly operating on large sets of dataand themselves becoming increasingly complex. In some cases, distributedcomputing systems are used to support such applications (e.g., where alarge database system distributes portions of data onto a landscape ofdifferent server nodes, and optimizes queries into sub-queries that getdistributed across that landscape). Unfortunately, significant efforthas to be spent managing that distribution both in terms of dataplacement and data access distribution methods, including thecomplexities of networking. If the landscape changes, if the dataorganization changes, or if the workload changes, significant work willbe required. More generally, the behavior of complex computing systemschanges over time, e.g., with new releases of applications, the additionof new intermediate software layers, new operating system releases, newprocessor models, and changing structural characteristics of data,increasing amounts of data, and different data access patterns.

BRIEF DESCRIPTION OF THE DRAWINGS

Various embodiments of the invention are disclosed in the followingdetailed description and the accompanying drawings.

FIG. 1 illustrates an embodiment of a computer system.

FIG. 2 illustrates the physical structure of the computer system as ahierarchy.

FIG. 3A depicts a virtualized computing environment in which multiplevirtual machines (with respective multiple guest operating systems) runon a single physical machine.

FIG. 3B depicts a virtualized computing environment in which multiplephysical machines collectively run a single virtual operating system.

FIG. 4A depicts an example of a software stack.

FIG. 4B depicts an example of a software stack.

FIG. 5 depicts an example of an operating system's view of hardware onan example system.

FIG. 6A depicts an example of a hyperthread's view of hardware on asingle node.

FIG. 6B depicts an example of a hyper-kernel's view of hardware on anexample system.

FIG. 7 depicts an example of an operating system's view of hardware onan example of an enterprise supercomputer system.

FIG. 8 illustrates an embodiment of a process for selectively migratingresources.

FIG. 9 illustrates an embodiment of a process for performinghierarchical dynamic scheduling.

FIG. 10 illustrates an example of an initial memory assignment andprocessor assignment.

FIG. 11 illustrates an updated view of the memory assignment and anunchanged view of the processor assignment.

FIG. 12 illustrates a memory assignment and an updated view of theprocessor assignment.

DETAILED DESCRIPTION

The invention can be implemented in numerous ways, including as aprocess; an apparatus; a system; a composition of matter; a computerprogram product embodied on a computer readable storage medium; and/or aprocessor, such as a processor configured to execute instructions storedon and/or provided by a memory coupled to the processor. In thisspecification, these implementations, or any other form that theinvention may take, may be referred to as techniques. In general, theorder of the steps of disclosed processes may be altered within thescope of the invention. Unless stated otherwise, a component such as aprocessor or a memory described as being configured to perform a taskmay be implemented as a general component that is temporarily configuredto perform the task at a given time or a specific component that ismanufactured to perform the task. As used herein, the term ‘processor’refers to one or more devices, circuits, and/or processing coresconfigured to process data, such as computer program instructions.

A detailed description of one or more embodiments of the invention isprovided below along with accompanying figures that illustrate theprinciples of the invention. The invention is described in connectionwith such embodiments, but the invention is not limited to anyembodiment. The scope of the invention is limited only by the claims andthe invention encompasses numerous alternatives, modifications andequivalents. Numerous specific details are set forth in the followingdescription in order to provide a thorough understanding of theinvention. These details are provided for the purpose of example and theinvention may be practiced according to the claims without some or allof these specific details. For the purpose of clarity, technicalmaterial that is known in the technical fields related to the inventionhas not been described in detail so that the invention is notunnecessarily obscured.

FIG. 1 illustrates an embodiment of a computer system. System 100 isalso referred to herein as an “enterprise supercomputer” and a“mainframe.” In the example shown, system 100 includes a plurality ofnodes (e.g., nodes 102-108) located in close proximity (e.g., locatedwithin the same rack). In other embodiments, multiple racks of nodes(e.g., located within the same facility) can be used in the system.Further, the techniques described herein can also be used in conjunctionwith distributed systems.

The nodes are interconnected with a high-speed interconnect (110) suchas 10-gigabit Ethernet, direct PCI-to-PCI, and/or InfiniBand. Each nodecomprises commodity server-class hardware components (e.g., a blade in arack with its attached or contained peripherals). In the example shownin FIG. 1, each node includes multiple physical processor chips. Eachphysical processor chip (also referred to as a “socket”) includesmultiple cores, and each core has multiple hyperthreads.

As illustrated in FIG. 2, the physical structure of system 100 forms ahierarchy (from the bottom) of hyperthreads (230), cores (210-224),physical processor chips (202-208), and nodes (102-108 (with nodes 104,106, etc. omitted from the figure and represented as ellipses)). Thetree depicted in FIG. 2 is of a fixed size, defined by the hardwareconfiguration.

As will be described in more detail below, each enterprise supercomputer(e.g., system 100) runs a single instance of an operating system. Boththe operating system, and any applications, can be standard commerciallyavailable software and can run on system 100. In the examples describedherein, the operating system is Linux, however other operating systemscan also be used, such as Microsoft Windows, Mac OS X, or FreeBSD.

In a traditional virtualized computing environment, multiple virtualmachines may run on a single physical machine. This scenario is depictedin FIG. 3A. In particular, three virtual machines (302-306) are runningthree guest operating systems on a single physical machine (308), whichhas its own host operating system. In contrast, using the techniquesdescribed herein, multiple physical machines (354-358) collectively runa single virtual operating system (352), as depicted in FIG. 3B.

One example of a software stack is depicted in FIG. 4A. Such a stack maytypically be used in traditional computing environments. In the stackshown in FIG. 4A, an application (402) sits above a database engine(404), which in turn sits upon an operating system (406), underneathwhich lies hardware (408). FIG. 4B depicts a software stack used in someembodiments. As with the stack shown in FIG. 4A, an application (452)sits above a database engine (454), which in turn sits upon an operatingsystem (456). However, underneath the operating system and above thehardware is a layer of software (referred to herein as a hyper-kernel)that observes the system running in real time and optimizes the systemresources to match the needs of the system as it operates. Thehyper-kernel conceptually unifies the RAM, processors, and I/O (InputOutput resources for example Storage, Networking resources) of a set ofcommodity servers, and presents that unified set to the operatingsystem. Because of this abstraction, the operating system will have theview of a single large computer, containing an aggregated set ofprocessors, memory, and I/O. As will be described in more detail below,the hyper-kernel optimizes use of resources. The hyper-kernel can alsohelp optimize other I/O system resources such as networks and storage.In some embodiments, based on observations and profiles of runningsoftware, performance indicators (hints) are provided to upper layers(e.g., database management systems) about the dynamic performance of thesystem that can further improve overall system performance.

The hyper-kernel can be ported to all major microprocessors, memory,interconnect, persistent storage, and networking architectures. Further,as hardware technology evolves (e.g., with new processors, new memorytechnology, new interconnects, and so forth), the hyper-kernel can bemodified as needed to take advantage of industry evolution.

As shown in FIG. 4B, operating system 456 is running collectively acrossa series of nodes (458-462), each of which has a hyper-kernel running onserver hardware. Specifically, the operating system is running on avirtual environment that is defined by the collection of hyper-kernels.As will be described in more detail below, the view for operating system456 is that it is running on a single hardware platform that includesall of the hardware resources of the individual nodes 458-462. Thus, ifeach of the nodes includes 1 TB of RAM, the operating system will haveas a view that it is running on a hardware platform that includes 3 TBof RAM. Other resources, such as processing power, and I/O resources cansimilarly be collectively made available to the operating system's view.

FIG. 5 depicts an example of an operating system's view of hardware onan example system. Specifically, operating system (502) runs on top ofprocessors 504-508 and physical shared memory 510. As explained above,an operating system can run on either a traditional computing system oron an enterprise supercomputer such as is shown in FIG. 1. In eithercase, the view of the operating system will be that it has access toprocessors 504-508 and physical shared memory 510.

FIG. 6A depicts an example of a hyperthread's view of hardware on asingle node. In this example, a node has four hyperthreads denoted H1(602) through H4 (608). Each hyperthread can access all portions ofphysical shared memory 612. Physical shared memory 612 is linear,labeled location 0 through a maximum amount, “max.” The node alsoincludes three levels of cache (610).

FIG. 6B depicts an example of a hyper-kernel's view of hardware on anexample system. In this example, three nodes (652-656) are included inan enterprise supercomputer. Each of the three nodes has fourhyperthreads, a physical shared memory, and cache (i.e., each node is anembodiment of node 600 shown in FIG. 6A). A hyperthread on a given node(e.g., node 652) has a view that is the same as that shown in FIG. 6A.However, the hyper-kernel is aware of all of the resources on all of thenodes (i.e., the hyper-kernel sees twelve hyperthreads, and all of thephysical shared memory). In the example shown in FIG. 6B, a givenhyperthread (e.g., hyperthread 658, “H1-4”) is labeled with its nodenumber (e.g., “1”) followed by a hyperthread number (e.g., “4”).

FIG. 7 depicts an example of an operating system's view of hardware onan example of an enterprise supercomputer system. The operating systemsees a plurality of “virtualized processors” denoted in FIG. 7 as P1through Pmax (702). The virtualized processors correspond to the totalnumber of hyperthreads across all nodes included in the enterprisesupercomputer. Thus, using the example of FIG. 6B, if a total of twelvehyperthreads are present across three nodes, a total of twelvevirtualized processors would be visible to an operating system runningon the enterprise supercomputer. The operating system also sees“virtualized physical memory” (704) that appears to be a large,physical, linear memory of a size equal to the total amount of physicalmemory across all nodes.

As will be described in more detail below, the hyper-kernel dynamicallyoptimizes the use of cache memory and virtual processor placement basedon its observations of the system as it is running. A “virtualprocessor” is a computing engine known to its guest operating system,i.e., one that has some operating system context or state. As will bedescribed in more detail below, a “shadow processor” is an anonymousvirtual processor, i.e., one that had been a virtual processor but hasnow given up its operating system context and has context known only tothe hyper-kernel.

Resource Virtualization

Memory Virtualization

As explained above, in the physical configuration, each node has anarray of memory addresses representing locations in memory. As such, ina physical configuration with three nodes (e.g., as depicted in FIG.6B), there are three memory locations each of which has address0x123456. In contrast, in the virtual configuration, all memoryaddresses are unique and represent the sum total of all memory containedin those three nodes. In the virtual configuration, all memory isshared, and all memory caches are coherent. In some embodiments, memoryis further subdivided into a series of contiguous blocks, withmonotonically increasing memory addresses. In the examples describedherein, each page has 4K bytes of memory, however, other subdivisionscan also be used, as applicable. The term“blocks” is used herein todescribe contiguous arrays of memory locations. In some embodiments, the“blocks” are “pages.”

Processor Virtualization

A virtual processor (e.g., virtual processor 706 of FIG. 7), as seen bythe operating system, is implemented on a hyperthread in the physicalconfiguration, but can be location independent. Thus, while theoperating system thinks it has 500 processors running on a singlephysical server, in actuality it might have 5 nodes of 100 processorseach. (Or, as is shown in FIG. 6B, the operating system will think ithas twelve processors running on a single physical server.) Thecomputation running on a virtual processor is described either by thephysical configuration on a hyperthread when the computation is running,or in a “continuation,” when the virtual processor is not running (i.e.,the state of an interrupted or stalled computation).

As used herein, a “continuation” represents the state of a virtualprocessor. Each continuation:

-   -   Has processor state (i.e., saved registers, etc.).    -   Has a set of performance indicators that guide a scheduler        object with information about how to intelligently assign        continuations to leaf nodes for execution.    -   Has a virtual-processor identifier that indicates the processor        the operating system thinks is the physical processor to which        this continuation is assigned.    -   Has an event on which this continuation is waiting (possibly        empty).    -   Has a state which includes: “waiting-for-event” or “ready.”

I/O Virtualization

I/O systems observe a similar paradigm to processors and memory. Deviceshave a physical address in the physical configuration and virtualaddresses in the virtual configuration. When migrating computations(described in more detail below), if for example, there are memorybuffers associated with I/O operations, the I/O devices used will likelyperform better if they are co-located with the memory with which theyare associated, and can be moved accordingly.

Resource Maps

Resource maps are used to translate between virtual and physicalconfigurations. The following are three types of resource maps used byenterprise supercomputers in various embodiments.

A “physical resource map” is a table that describes the physicalresources that are available on each node. It contains, for example, thenumber and type of the processors on each node, the devices, the memoryavailable and its range of physical addresses, etc. In some embodiments,this table is read-only and is fixed at boot time.

An “initial virtual resource map” is fixed prior to the booting of theoperating system and describes the virtual resources that are availablefrom the point of view of the operating system. The configuration isreadable by the operating system. In some cases, it may be desirable toconfigure a system (from the viewpoint of the operating system) thatdoes not match, one-to-one, with the underlying hardware resources. Asone example, it may be desirable for the operating system to have morememory and fewer cores. This can be accomplished by changing the ratioof memory to cores, i.e., by modifying the initial virtual resource map.

A “current resource map” is created and maintained by each hyper-kernelinstance. This map describes the current mapping between the virtualresource map and the physical resource map from the point of view ofeach node. For each entry in the virtual resource map, a definition ofthe physical resources currently assigned to the virtual resources ismaintained. Initially (e.g., at boot time), the current resource map isa copy of the initial virtual resource map. The hyper-kernel modifiesthe current resource map over time as it observes the characteristics ofthe resource load and dynamically changes the mapping of physicalresources to virtual resources (and vice-versa). For example, thedefinition of the location of the Ethernet controller eth27 in thevirtualized machine may at different times refer to different hardwarecontrollers. The current resource map is used by the hyper-kernel todynamically modify the virtual hardware resource mappings, such as thevirtual memory subsystem, as required.

Resource Migration Overview

Using the techniques described herein, virtualized resources can bemigrated between physical locations. As explained above, the operatingsystem is provided with information about the virtualized system, butthat information need not agree with the physical system.

In the following example, suppose an enterprise supercomputer holds alarge in-memory database, larger than can fit into a single node. Partof the database is in a first node, “node1.” Suppose one of the cores ona different node, “node2,” is trying to access data that is owned bynode1 and that does not reside locally in a cache on node2. The core onnode2 will receive a memory access violation because it is trying toaccess data that it believes it should be able to access (but cannot).As will be described in more detail below, the exception is handled inthe hyper-kernel.

One way that the situation can be resolved is by moving the needed areaof memory to node2, and then returning control back to the operatingsystem (which, in turn, returns it back to the database system). Thesoftware can then proceed as intended (i.e., as if the access violationnever occurred).

In many cases, there may be one or more other cores in other nodes(e.g., “node3”) that are also trying to access the same area block ofmemory as needed by node2 above. Node3 might be attempting to access thesame data, or it might be accessing different data contained in thememory that was moved (also referred to as “false sharing”). The datacould be moved to node3, but if the core on node2 asks for the data asecond time, the data would need to be moved back to node2 (i.e.,potentially moving the data back and forth repeatedly), which can beslow and wasteful. One way to avoid moving data back and forth betweencores is to recognize that both cores and the associated block of datashould be co-located. Using the techniques described herein, the memoryand the computation can be migrated so that they reside on the samenode. Doing so will result in a higher likelihood of faster access todata, and a higher probability of sharing data stored in local caches.

When the access violation occurs, an event is triggered (in a systemdependent way) to which the hyper-kernel responds. One example of howsuch an event can be handled is by the invocation of a panic routine.Other approaches can also be used, as applicable. As will be describedin more detail below, the hyper-kernel examines the cause of the eventand determines an appropriate strategy (e.g., low level transaction) forhandling the event. As explained above, one way to handle the event isfor one or more blocks of hyper-kernel virtualized memory to betransferred from one node's memory to another node's memory. Thetransfer would then be initiated and the corresponding resource mapswould be updated. A continuation would be built poised to be placed in alocal table in shared memory called the event table (discussed below) sothat the next thing the continuation does when it is resumed would be toreturn control to the operating system after the transfer is completed.A decision could also be made to move the virtual processor to the nodethat contains the memory being requested or to move the virtualizedmemory (and its virtualized memory address) from one node to another. Invarious embodiments, the hyper-kernel makes three decisions whenhandling an event: which (virtual) resources should move, when to movethem, and to where (in terms of physical locations) they should move.

TidalTree

The physical hierarchical structure depicted in FIG. 2 has an analogoussoftware hierarchy comprising a set of “scheduler objects” (i.e., datastructures), each of which has a set of characteristics described below.The scheduler objects form a “TidalTree,” which is an in-memory treedata structure in which each node of the tree is a scheduler object.Each scheduler object corresponds to an element of the physicalstructure of the supercomputer (but not necessarily vice versa), sothere is one node for the entire machine (e.g., node 100 as shown inFIG. 2), one node for each physical node of the system (e.g., node 102as shown in FIG. 2), one node for each multicore socket on the physicalnodes that comprise the entire machine (e.g., node 202 as shown in FIG.2), one node for each core of each socket (e.g., node 210 as shown inFIG. 2), and one node for each hyperthread on that core (e.g., node 232as shown in FIG. 2).

Each scheduler object s:

-   -   Is associated with a physical component (e.g., rack, blade,        socket, core, hyperthread).    -   Except for the root of the tree, has a parent scheduler object        which is partly responsible for directing its operations (as        explained in more detail below).    -   Has a set of children each of which is a scheduler object. This        is the null set for a leaf (e.g., hyperthread) node. As        explained in more detail below, it is the responsibility of a        scheduler object s to manage and assign (or re-assign) work to        its children, and indirectly to its grandchildren, etc. (i.e., s        manages all nodes in the subtree rooted at s).    -   Has a work queue, which is a set of continuations (as described        earlier).    -   Has a (possibly empty) set of I/O devices that it also has the        responsibility to manage and assign (or re-assign) work.

Each node can potentially be associated with a layer of some form ofcache memory. Cache hierarchy follows the hierarchy of the tree in thesense that the higher the scheduler object is, the slower it willusually be for computations to efficiently utilize caches at thecorresponding level of hierarchy. The cache of a scheduler objectcorresponding to a physical node can be a cache of memory correspondingto that node. The memory on the physical node can be thought of as acache of the memory of the virtual machine.

Resource Migration—Additional Information

The hyper-kernel simulates part of the virtual hardware on which thevirtual configuration resides. It is an event-driven architecture,fielding not only translated physical hardware events, but soft events,such as receipt of inter-node hyper-kernel messages generated byhyper-kernel code running on other nodes.

As explained above, when an interrupt event significant to thehyper-kernel occurs, the hyper-kernel makes a decision of how to respondto the interrupt. Before control is returned to the operating system,any higher priority interrupts are recognized and appropriate actionsare taken. Also as explained above, the hyper-kernel can make threeseparate decisions: (1) which resources to migrate upon certain events,(2) when to migrate them, and (3) to where those resources should move.

In the following example, suppose a scheduler object “s” in a virtualmachine is in steady state. Each scheduler object corresponding to aphysical node has a set of physical processor sockets assigned to it.Hyperthreads in these sockets may or may not be busy. The physical nodealso has some fixed amount of main memory and a set of I/O devices,including some network devices. Scheduler object s, when correspondingto a node, is also responsible for managing the networks and other I/Odevices assigned to nodes in the subtree rooted at s. The following is adescription of how resources can migrate upon either synchronous orasynchronous events.

Migrations Triggered by Synchronous Events

In the following example, suppose there exists a leaf node schedulerobject s, and virtual processor p assigned to s. Leaf node scheduleobject s is assumed to be executing an application or operating systemcode on behalf of an application. Assuming the leaf node is not in aninfinite loop, p will eventually run out of work to do (i.e., stall) forsome reason (e.g., waiting for completion of an I/O operation, pagefault, etc.). Instead of allowing p to actually stall, the hyper-kerneldecides whether to move the information about the stalled computation tosome other node, making one of that other node's processors“responsible” for the stalled continuation, or to keep the“responsibility” of the stalled computation on the node and instead movethe relevant resources to the current node.

The stall is thus handled in either of two ways: either the computationis moved to the physical node that currently has the resource, or elsethe resource is moved to the physical node that has requested theresource. Example pseudo code for the handling of a stall is providedbelow (as the “OnStall” routine) in the “EXAMPLE ROUTINES” sectionbelow.

Decisions such as how to handle a stall can be dependent on many things,such as the order of arrival of events, the state of the computationrunning on the virtual machine, the state of the caches, the load on thesystem or node, and many other things. Decisions are made dynamically,i.e., based on the best information available at any given point intime.

Recording Stalled Computations

Stalled computations are recorded in a data structure referred to as a“continuation.” A continuation has a status that can be, for example,“waiting-for-event” or “ready.” A stalled computation gets recorded as anewly created continuation with status “waiting-for-event.” Once thereason for stalling is satisfied (e.g., due to detection of the event),the status of the corresponding continuation is changed to “ready.” Eachcontinuation with status “ready” is stored in a “wait queue” of ascheduler object so that eventually it gets scheduled for execution. Incontrast, any continuation with status “waiting-for-event” will not bestored in any scheduler object's wait queue. Instead, it is stored inthe local shared memory of the physical node where the hardware eventthat stalled the corresponding computation is expected to occur, such asreceipt of a missing resource.

Additionally, the newly created continuation is associated with thestalling event that caused its creation. This mapping between (stalling)events and continuations awaiting these events permits fast dispatch ofasynchronous events (see the “handleEvent” described below). The mappingbetween continuations and events is stored in a table called “eventtable” and is kept in the shared memory of the corresponding physicalnode. Each physical node has its own event table, and an event table ofa physical node is directly addressable by every core on that physicalnode. All anticipated events recorded in an event table of a physicalnode correspond to hardware events that can occur on that physical node.The scheduler object s mapped to a physical node n represents n, and theevent table of n is associated with s. In some cases, severalcontinuations may be waiting on the same event, and so somedisambiguation may be required when the event is triggered.

Continuations are built using the “InitContinuation” routine. If adecision is made to move the computation, the remote physical nodeholding the resource will build a continuation that corresponds to thestalled computation and will store it in the remote physical node'sevent table. When that continuation resumes, the resource will beavailable. In effect, the hyper-kernel has transferred the virtualprocessor to a different node.

In the case where a decision is made to move the resource, the node thathas experienced the stall requests the transfer of the resource andbuilds a continuation using InitContinuation and stores it in the localevent table. Upon receipt of the resource, the continuation is attachedto an appropriate node in the TidalTree, and when that continuation isresumed, the resource will be generally be available and visible. Ineffect, the virtual resource has been transferred to the node thatrequested it.

Note that by placing continuations in event tables, it is guaranteedthat the processor that receives the event will quickly find the relatedcontinuations in its local event table. The reason for the stall in thecomputation will have been satisfied.

Having dealt with the stall, the virtual-processor p will in effect besuspended. In between processing the stall and finding a newcontinuation to resume, p becomes an “anonymous shadow processor,” i.e.,a processor with no identity known to the operating system. This shadowprocessor then looks for a new continuation to resume. An example ofthis is shown below in the “assignProcessor” routine described in moredetail below.

Notation

Let e be the event that stalled virtual processor p. Assume that e istriggered by local hardware of some physical node n. In particular,assume r is the resource, which caused the stalling event to occur.Resource r could be a block of memory, or an I/O operation, or a networkoperation. Assume that p is assigned to scheduler object s, whichbelongs to the subtree rooted at the scheduler object that representsphysical node n.

On-Stall

Pseudo code for an example on-stall routine is provided below in the“EXAMPLE ROUTINES” section. The migration-continuation function returnstrue if and only if processor p in node n decides that the resourceshould not move, i.e., the computation should move. This can bedetermined by a number of factors such as history and frequency ofmovement of r between nodes, the type of r, the cost of movement, thenumber of events in n's local event table waiting for r, system load,etc. For example, it may not be desirable to move a resource if there isa continuation stored in n's local event table that is waiting for it.

A variety of patterns of events that would benefit from migrationsexist. One approach to describing these patterns of events, like accessviolations, is in formal language theory. Regular (i.e., Chomsky type-3)languages can be recognized by finite state automata. In addition, usinga compact and flexible notation, a description of the events that areobserved can be made as sentences (or Chomsky sequences) in the regularlanguage, and the recognition modeled as state transitions in thecorresponding finite state automaton. When the full Chomsky sequence ofevents is seen, migration-continuation gets evaluated accordingly: ifthe finite state automaton accepts the Chomsky sequence, the conditionis met, otherwise, it is not met. The length of the minimized finitestate machine defines the amount of history that needs to be kept.

In various embodiments, all events happen locally, and the hyper-kernelon the physical node receiving the event must handle it—trulysynchronous events are not assumed to occur between physical nodes. Tocoordinate migration strategy between nodes, “messages” are used.Message “sends” are synchronous from a node's point of view, but message“receives” are asynchronous, in that a processor or shadow processor, ingeneral, does not wait for receipt of a message. When messages arrive,they are dealt with by the hyper-kernel as a virtual interrupt. In oneembodiment, the hyper-kernel will not allow a processor to resume acontinuation while there are messages waiting to be handled. Therefore,before control is transferred back to the operating system, the queue ischecked, and any messages are dealt with prior to the transfer ofcontrol back to the operating system.

For scheduler object s and continuation c, a cost function cost(s,c) canbe used to guide the search up the tree. If multiple ancestors of p havenon-empty queues, then p may not want to stop its search at the firstancestor found with a nonempty wait queue. Depending on the metrics usedin the optimizing strategy, p's choice may not only depend on thedistance between p and its chosen ancestor but on other parameters suchas length of the wait queues.

A function, find-best-within(s), can be used to return the “best-fit”continuation in a (non-empty) wait queue of a scheduler object. Examplesof parameters that can be considered include:

1. Position in the queue

2. The relationship between p and the last location recorded in thecontinuation (the closer those locations are the better it may be forreusing cache entries).

3. Performance indicators recorded in the continuations in the queue.

The cost and find-best-within functions can be customized as applicablewithin a given system.

Migrations Triggered by Asynchronous Events

Examples of asynchronous events include: receipt of a packet, completionof an I/O transfer, receipt of a resource, receipt of a messagerequesting a resource, etc. Generally, a hyper-kernel that receives anevent corresponding to a hardware device managed by the operating systemneeds to deliver a continuation associated with that event to ascheduler object s. By doing so, s will make this continuation availableto an appropriate scheduler object and then ultimately to thecomputation managed by the operating system represented by thatcontinuation. If, on the other hand, the event is the receipt of amessage from a hyper-kernel on another physical node, the hyper-kernelcan handle it directly.

To simplify explanation, in the examples described herein, an assumptionis made that there is only one continuation associated with an event.The procedures described herein can be generalized for the case wheremultiple continuations are associated with the same event, as needed.

In some embodiments, the search for a scheduler object on which to placethe continuation starts at the leaf of the tree that built thecontinuation and then proceeds upward (if the computation previouslyexecuted on this node). By doing so, the likelihood of reusing cacheentries is increased.

Handle-Event

Pseudo code for an example handle-event routine is provided below in the“EXAMPLE ROUTINES” section. The cost function, cost(s,c), is a functionthat helps determine the suitability of assigning c to scheduling objects. The cost function can depend on a variety of parameters such as thesize of the wait queues, the node traversal distance between s and theoriginal scheduling node for c (to increase the probability that cacheentries will be reused), and the history of the virtual processor, thephysical-processor, and the continuation. If the wait queues of thescheduler objects close to s already contain too many continuations,then it may take a relatively longer time until any newly addedcontinuation is scheduled for execution. Example conditions contributingto cost(s,c) are described below, and the conditions can be customizedas applicable.

Costs

Cost functions are used to evaluate options when selecting continuationsand scheduling objects. Cost functions can be expressed as the summationof a sum of weighted factors:cost=w ₁ f ₁ ^(x) ₁ +w ₂ f ₂ ^(x) ₂ + . . . +w _(n) f _(n) ^(x) _(n),

where w_(i) indicates the importance of the corresponding factor andx_(i) indicates an exponential.

Examples of factors f_(i) are listed for each of the costs below.Weights w_(i) and exponents x_(i) can be determined in a variety ofways, such as empirically and by simulation. Initial weights andexponents can be tuned to various application needs, and can be adjustedby an administrator to increase performance. The weights can be adjustedwhile the system is active, and changing weights does not change thesemantics of the hyper-kernel, only the operational performancecharacteristics.

Examples of the factors that can be considered include:

-   -   Length of time since the last processor evacuated this scheduler        object.    -   Height of the scheduler object in the TidalTree.    -   Length of the work queue.    -   Reservation status (i.e., it may be the case that some        application has reserved this resource for a specific reason).    -   Node specification (i.e., the node itself might have been taken        out of service, or is problematic, has in some way a specialized        function, etc.).    -   Age of the continuation in the queue.    -   Last physical processor to run this continuation.    -   Last virtual processor to run this continuation.    -   Node on which this continuation was last executing.    -   The “temperature” of the cache. (A cache is “warm” when it has        entries that are likely to be reused. A cache is “cold” when it        is unlikely to have reusable cache entries.)    -   Group membership of the continuation (i.e., the continuation may        be part of a computation group, each element of which has some        affinity for other members of the group).    -   Performance Indicators (Hints) and special requirements.

EXAMPLES

“OnStall” and “AssignProcessor”

FIG. 8 illustrates an embodiment of a process for selectively migratingresources. In some embodiments, process 800 is performed by ahyper-kernel, such as in conjunction with the OnStall routine. Theprocess begins at 802 when an indication is received that a core (orhyperthread included in a core, depending on whether the processor chipsupports hyperthreads) is blocked. As one example, suppose a hyperthreadreceives a request, directly or indirectly, for a resource that thehyperthread is not able to access (e.g., RAM that is located on adifferent node than the node which holds the hyperthread). When thehyperthread fails to access the resource (i.e., an access violationoccurs), an interrupt occurs, which is intercepted, caught, or otherwisereceived by the hyper-kernel at 802. In particular, the hyper-kernelreceives an indication at 802 that the hyperthread is blocked (becauseit cannot access a resource that it has been instructed to provide). Inaddition to reporting its blocked state, the hyperthread providesinformation such as the memory address it was instructed to access andwhat type of access was attempted (e.g., read, write, or modify).

At 804, the hyper-kernel determines whether the needed memory should bemoved (e.g., to the node on which the blocked hyperthread is located),or whether the requesting process should be remapped (i.e., the virtualprocessor should be transferred to a different node). The decision canbe based on a variety of factors, such as where the needed memory islocated, the temperature of the cache, the workload on the node holdingthe hyperthread, and the workload on the node holding the needed memory(e.g., overworked or underworked). In some embodiments, the workload ofa node is determined based at least in part on the average queue lengthin the TidalTree.

If the hyper-kernel determines that the memory should be moved, thehyper-kernel uses its current resource map to determine which node islikely to hold the needed memory and sends a message to that node,requesting the resource. The hyper-kernel also creates a continuationand places it in its event table. The hyperthread that was blocked at802 is thus freed to take on other work, and can be assigned to anothervirtual processor using the assignProcessor routine.

The hyper-kernel checks its message queue on a high-priority basis. Whenthe hyper-kernel receives a message from the node it contacted (i.e.,the “first contacted node”), in some embodiments, one of two responseswill be received. The response might indicate that the first contactednode has the needed resource (and provide the resource). Alternatively,the message might indicate that the contacted node no longer has theresource (e.g., because the node provided the resource to a differentnode). In the latter situation, the first contacted node will providethe identity of the node to which it sent the resource (i.e., the“second node”), and the hyper-kernel can send a second messagerequesting the resource—this time to the second node. In variousembodiments, if the second node reports to the hyper-kernel that it toono longer has the resource (e.g., has provided it to a third node), thehyper-kernel may opt to send the continuation to the third node, ratherthan continuing to request the resource. Other thresholds can be used indetermining whether to send the continuation or continuing the resource(e.g., four attempts). Further, a variety of criteria can be used indetermining whether to request the resource or send the continuation(e.g., in accordance with a cost function).

In the event the hyper-kernel determines that the continuation should betransferred (i.e., that the computation should be sent to another noderather than receiving the resource locally), the hyper-kernel providesthe remote node (i.e., the one with the needed resource) withinformation that the remote node can use to build a continuation in itsown physical address space. If the remote node (i.e., the one receivingthe continuation) has all of the resources it needs (i.e., is inpossession of the resource that caused the initial access violation),the continuation need not be placed into the remote node's event table,but can instead be placed in its TidalTree. If the remote node needsadditional resources to handle the continuation, the receivedcontinuation is placed in the remote node's event table.

FIG. 9 illustrates an embodiment of a process for performinghierarchical dynamic scheduling. In some embodiments, process 900 isperformed by a hyper-kernel, such as in conjunction with theassignProcessor routine. The process begins at 902 when an indication isreceived that a hyperthread should be assigned. Process 900 can beinvoked in multiple ways. As one example, process 900 can be invokedwhen a hyperthread is available (i.e., has no current work to do). Thiscan occur, for example, when the hyper-kernel determines (e.g., at 804)that a continuation should be made. The previously blocked hyperthreadwill become available because it is no longer responsible for handlingthe computation on which it blocked (i.e., the hyperthread becomes an“anonymous shadow processor”). As a second example, process 900 can beinvoked when a message is received (e.g., by the hyper-kernel) that apreviously unavailable resource is now available. The hyper-kernel willneed to locate a hyperthread to resume the computation that needed theresource. Note that the hyperthread that was originally blocked by thelack of a resource need not be the one that resumes the computation oncethe resource is received.

At 904, the TidalTree is searched for continuations that are ready torun, and one is selected for the hyperthread to resume. In variousembodiments, the TidalTree is searched from the leaf-level, upward, anda cost function is used to determine which continuation to assign to thehyperthread. As one example, when a hyperthread becomes available, thecontinuation that has been queued for the longest amount of time couldbe assigned. If no continuations are waiting at the leaf level, or areoutside a threshold specified by a cost function, a search will beperformed up the TidalTree (e.g., the core level, then the socket level,and then the node level) for an appropriate continuation to assign tothe hyperthread. If no appropriate continuations are found for thehyperthread to resume at the node level, the hyper-kernel for that nodecontacts the root. One typical reason for no continuations to be foundat the node level is that there is not enough work for that node to befully utilized. In some embodiments, the node or a subset of the nodecan enter an energy conserving state.

Time Sequence

For expository purposes, in the example, a “swapping” operation is usedto transfer continuations and memory, but in fact that's not necessaryin all embodiments.

FIG. 10 illustrates an example of an initial memory assignment andprocessor assignment. Specifically, region 1002 of FIG. 10 depicts ahyper-kernel's mapping between physical blocks of memory (on the lefthand side) and the current owner of the memory (the center column). Theright column shows the previous owner of the memory. As this is theinitial memory assignment, the current and last owner columns hold thesame values. Region 1004 of FIG. 10 depicts a hyper-kernel's mappingbetween system virtual processors (on the left hand side) and thephysical nodes (center column)/core numbers (right column).

Suppose virtual processor P00 makes a memory request to read location8FFFF and that the hyper-kernel decides to move one or more memoryblocks containing 8FFFF to the same node as P00 (i.e., node 0). Block8FFFF is located on node 2. Accordingly, the blocks containing 8FFFF aretransferred to node 0, and another block is swapped out (if evacuationis required and the block is valid), as shown in FIG. 11.

Next, suppose virtual processor P06 makes a memory request to readlocation 81FFF. The contents of this block have been moved (as shown inFIG. 11) to node 0. The hyper-kernel may determine that, rather thanmoving the memory again, the computation should be moved. Accordingly,virtual processor P06 is moved to node 0, and may be swapped withvirtual processor P01, as shown in FIG. 12.

Performance Information

Locks and Other Synchronizers

In various embodiments, the use of synchronization mechanisms like locksis minimal. Locks are used, for example, to insert queue and removequeue continuations on scheduler objects and to maintain the eventtable.

Code Path Lengths

In some embodiments, the (maximum) length of all code paths isdetermined through a static code analysis, resulting in estimable andbounded amounts of time spent in the hyper-kernel itself. All datastructures can be pre-allocated, for example, as indexed arrays. Thenodes of the TidalTree are determined at boot time and are invariant, asare the number of steps in their traversal. One variable lengthcomputation has to do with the length of the work queues, but even thatcan be bounded, and a worst-case estimate computed. In otherembodiments, other variable length computations are used.

Static Storage

In various embodiments, all data structures needed in the hyper-kernelare static, and determined at boot time, so there is no need for dynamicmemory allocation or garbage collection.

Physical Memory

All memory used by the hyper-kernel is physical memory, so no pagetables or virtual memory is required for its internal operations(except, e.g., to manage the virtual resources it is managing), furtherhelping the hyper-kernel to co-exist with an operating system.

Sharing Data and Maintaining Consistency

In some cases, e.g., to preserve the conceptual integrity of the virtualmachine being presented to the operating system, changes in one node'sdata structures are coordinated with corresponding ones in a differentnode. Many of the data structures described herein are “node local,” andeither will not need to move, or are constant and replicated. The datastructures that are node local are visible to and addressable by allhyperthreads on the node. Examples of data structures that are not nodelocal (and thus require coordination) include the current resource map(or portions thereof), the root of the TidalTree, and migratorycontinuations (i.e., continuations that might have to logically movefrom one node to another).

A variety of techniques can be used to maintain a sufficient degree ofconsistency. Some are synchronous and assume all changes are visible atthe same time to all nodes (i.e., “immediate consistency”). Others allowa more relaxed solution and strive for “eventual consistency.” Asmentioned above, physical nodes of an enterprise supercomputer areconnected via one or more high speed interconnects. Multiple instancesof hyper-kernels are interconnected to pass messages and resources backand forth between physical nodes.

Updating the Current Resource Map

Each physical node n starts off (e.g., at boot time) with the same copyof the physical resource map, the initial virtual resource map, and thecurrent resource map. Each node maintains its own copy of the currentresource map.

In some embodiments, each entry for resource r in the current resourcemap has the following:

1. A local lock, so that multiple hyperthreads on a physical-node cannotmodify r at the same time.

2. A node number specifying the node that currently owns the resource.

3. A count k of the number of times n has requested r since the lasttime it owned r.

4. A boolean which when set signifies that this node n wants r.

5. A boolean which when set signifies that this node has r but is in theprocess of transferring it, in which case the node number specifies thenew owner.

In some embodiments, the count k is used to deal with unbounded chasingof resources. If k exceeds a threshold, a determination is made that itis better to move the newly built continuation rather than chasing theresource around the system.

The following is an example of a mechanism for initiating migration ofresources and receiving resources. Key transactions include thefollowing:

1. Node n sends a request for resource r to n′.

2. Node n′ receives a request for resource r from n.

3. Node n′ may send a “deny” message to n under certain circumstances,otherwise it can “accept” and will send the resource r.

4. Node n will receive a “deny” message from n′ if the resource r cannotbe sent by n′ at this point in time. It may be that r is needed by n′,or it may be that r is being transferred somewhere else at the arrivalof the request. If the request is denied, it can send a “forwarding”address of the node to which it's transferring the resource. It may bethat the forwarding address is n′ itself, which is the equivalent of“try again later.” When node n receives the deny message, it can resendthe request to the node suggested by n′, often the new owner of theresource. To avoid n chasing the resource around the system, it can keeptrack of the number of attempts to get the resource, and switchesstrategy if the number of attempts exceeds a threshold.

5. Node n will receive the resource r if n′ can send the resource. Inthis case, n needs to schedule the continuation c that was awaiting r,so that c can be resumed.

TidalTree Root

In some embodiments, one physical node of the set of nodes in the systemis designated as a “master node.” This node has the responsibility atboot time for building the initial virtual resource map and other datastructures, replicating them to the other nodes, and booting theoperating system (e.g., Linux). The master node can be just like anyother node after the system is booted up, with one exception. At leastone physical node needs to store the root of the TidalTree. The masternode is one example of a place where the root can be placed. Updates tothe event queue of the TidalTree root scheduling object are handled ineach node by sending a message to the master node to perform the update.

Over time, the hyper-kernel will adapt and locality will continuallyimprove if resource access patterns of the operating system and theapplication permit.

Continuations

As explained above, physical memory addresses across all nodes are notunique. In some embodiments, the inclusion of physical memory addressesin continuations can be avoided by using partitioned integer indices todesignate important data structures in the hyper-kernel. In the event anaddresses needs to be put into a continuation, care is taken in themove, since the address is a physical address of the source, and bearsno relationship with the physical address in the destination. Moving acontinuation means copying its contents to the destination node asdiscussed above, and remapping any physical addresses from the source tothe target.

Timestamps

In some embodiments, access to a free-running counter is visible to allof the nodes. In the absence of this, free-running counters on each nodecan also be used. Counters in continuations are mapped between thesource and destination.

Handling of Disks and Persistent Flash

Where a needed resource is on disk (or persistent flash), in someembodiments, such resources are treated as having a heaviergravitational field than a resource such as RAM. Accordingly, disk/flashresources will tend to not migrate very often. Instead, continuationswill more frequently migrate to the physical nodes containing therequired persistent storage, or to buffers associated with persistentstorage, on a demand basis.

Operating System Configuration

There are many ways to configure an operating system. For servers, anassumption can be made that its operating system is configured to onlyrequire a small set of resource types from the virtual machineimplemented by the hyper-kernel: storage that includes linear blockarrays, networks, processors, memory, and internode interconnects. As aresult, the complexity of the operating system installation can bereduced.

Example Data Structures and Functions

The following section provides a list of examples of data structures andfunctions used in various embodiments.

init-continuation: Initializes a continuation when a computation isstalled.

assignProcessor: Routine that assigns a new continuation to a shadowprocessor (if possible).

on-stall(r): Stalling event occurs for resource r.

migrate-computation(computational-state,r,n): Message to requestmigration of a computational state to another node n which you hope hasresource r.

on-interrupt(i): Software interrupt i occurs.

handle-event(e): Routine executed when the hyper-kernel is called on tohandle an asynchronous event.

request-resource(r,n): Request transfer of resource r from node n.

initiate-send-resource(r,n): Start sending resource r to node n.

on-request-transfer-response(r,n,b): The requested transfer of r from nwas accepted or rejected. b is true if rejected.

on-transfer-requested (r,m): Receive a request from m for resource r.

on-resource-transferred(r,n): Ack of resource r has been received fromn.

on-receive-resource (r,n): Resource r has been received from n.

migration-continuation(r): True if and only if it is better to migrate acontinuation than move a resource.

parent(s): Returns the parent scheduler-object of scheduler object s.

cost(s,c): Used to evaluate placement of continuation c in thewait-queue of scheduler-object s.

find-best-within(s): A cost function that returns a continuation storedin the wait-queue of scheduler-object s.

conserve-energy: Enter low power mode.

resume-continuation(c): Resume the computation represented by c in theprocessor executing this function at the point.

valid(i): Boolean function that returns true if and only if interrupt iis still valid.

initialize(best-guess): Initializes cost variable best-guess.

insert-queue(s,c): Insert continuation c into the wait-queue ofscheduler-object s.

return-from-virtual-interrupt: Resume execution that was temporarilypaused due to the interrupt.

r.owner: Returns the node where resource r is local.

r.e: Resource r is awaiting this event.

e.r: This event is for resource r.

e.continuation: When this event occurs, need to resume continuation.

get-state( ): Returns processor's state.

scheduler-object(p): Returns scheduler-object currently associated withprocessor p.

on-request-transfer-response(r,m, response): Response to request oftransferring resource r from node m. Response can be either true if“rejected” or false if “accepted.”

Example Routines

The following are pseudo-code examples of routines used in variousembodiments. In the following, functions that start with “on-” areasynchronous events or messages coming in.

==========================

init-continuation(computational-state)

==========================

/* InitContinuation by processor p awaiting resource r with hints h */

c=allocate continuation

c.state=computational-state

c.last=scheduler-object(p)

c.state=waiting-for-event

c.hints=h

e=allocate event in event-table

e.resource=r

e.continuation=c

return c

end InitContinuation

==========================

assignProcessor

==========================

/* Once processor p in physical node n becomes a shadow processor, itgives up its O/S identity and starts looking for a continuation withwhich to resume execution. p will look for such a continuation inwait-queues as follows: */

s=scheduler-object (p)

initialize (best-guess)

best-s=nil

/* traverse upwards, keeping track of best candidate */

/* assume there is a locally cached copy of the root */

repeat

-   -   guess=cost (s)    -   if guess>best-guess    -   then        -   best-guess=guess        -   best-s=s    -   s=parent (s)

until s=nil

if best-s< >nil

then

-   -   c=find-best-within (best-s)    -   resume-continuation (c)

else conserve-energy

end assignProcessor

==========================

on-stall(r)

==========================

/* OnStall is invoked when the hardware detects an inconsistency betweenthe virtual and physical configurations. More specifically, node nrequests resource r which the hardware cannot find on node n. */

if migration-continuation (r)

then

-   -   /* send the computation to node n */    -   nn=owner(r)    -   /* node n believes resource is probably at node nn */    -   migrate-computation (r,nn)

else

-   -   /* request the resource r */    -   c=init-continuation(get-state( ))    -   /* insert code here to insert c into the local event-table */    -   request-resource(r,owner(r))

assignProcessor /* At this point, p is an anonymous shadow processor */

-   -   /* p needs to find some work to do */

end OnStall

==========================

on-migrate-computation(computational-state, r,n)

==========================

-   -   /* the remote node gets the message from n to receive a        continuation. Note: c in this case is the contents of the        continuation, not the continuation itself. */

c=InitContinuation /* with the information in the request */

c.state=computational-state

e=insert c into the local event-table

handle-event (e)

end on-migrate-computation

==========================

on-interrupt(i)

==========================

/* When a processor p (in subtree of physical node n) is interrupted byi (using a very low level mechanism specific to the particular hardwaredesign), p does the following: */

while valid (i)

-   -   e=event-table (i) /* find the event corresponding to i */    -   handle-event (e)    -   i=next-queued-interrupt

end while

/* resume prior execution */

return-from-virtual-interrupt

end on-interrupt

==========================

handle-event(e)

==========================

/* An event occurred. Move it from the event table to the bestscheduler-object. */

c=e.continuation /* find the continuation for event e */

event-table (i).clear=true /* remove the event from the table */

e.complete=true /* mark e as completed */

c.state=ready

/* now find out the best place to put c */

s=c.last

initialize (best-guess)

/* look for best choice */

/* assume there is a locally cached copy of the root */

repeat

-   -   guess=cost (s,c)    -   if guess>best-guess    -   then        -   best-guess=guess        -   best-s=s    -   s=parent (s)

until s=nil

insert-queue (best-s,c)/* queue up c in the wait-queue of best-s */

end handle-event

==========================

request-resource (r,n)

==========================

/* When a node n needs a resource r owned by node n′ the resource isrequested, but the request may not be satisfied because someone elsemight have beaten you to request it or n′ is currently using it. */

-   -   current-resource-map(r).wanted=true    -   request-transfer(owner(r),r) /* send a request to the owner of r        */        -   /* requesting r's transfer */

return

==========================

on-request-transfer-response (r, m, is-rejected)

==========================

/* Now, consider that you are a node getting a response from a previousrequest to a node for a resource r. When the response to this requestcomes in, it can be accepted or rejected. */

if is-rejected then /* resource has been transferred to m */ increment kif k > threshold   then    /* you don't want to go chasing aroundforever*/    /* trying to get the resource. Give up */   migrate-computation(r,m)    return   else    request-transfer(r,m) /*try again */    return  else   /* request was not rejected and r is theresource */   r.k = 0   r.wanted = false /* resource has been moved */  r.owner = me /* set the owner to n (i.e., “me”) */   if the resourceis memory,    update the hardware memory map with the new memory return

==========================

on-transfer-requested (r,n)

==========================

/* When a resource request for r comes from node n, if transfer inprogress to owner(r), deny the request */

if r.being-transferred

then

-   -   send-request-response (r, owner(r), true)

else

-   -   /* transfer of resource is accepted */    -   r.transferring=true    -   initiate-send-resource(r)    -   if type(r)=memory    -   then update local memory map    -   send-request-response (r, owner(r), false)

return

==========================

on-resource-transferred (r,n)

==========================

/* When an acknowledgement comes in that the transfer is complete */

r.owner=n

r.transferring=false

return

==========================

on-receive-resource(r,n)

==========================

/* Now we receive a message with the requested resource r from n*/

r.k=0

r.wanted=false/* clear the bit saying that it's wanted */

r.owner=me /* set the owner to n (i.e., “me”) */

if the resource is memory,

-   -   update the memory map with the new memory

send-resource-transferred(r,n)

handle-event(r.e) /* the event we've been waiting for has occurred */

return

Although the foregoing embodiments have been described in some detailfor purposes of clarity of understanding, the invention is not limitedto the details provided. There are many alternative ways of implementingthe invention. The disclosed embodiments are illustrative and notrestrictive.

What is claimed is:
 1. A computer system, comprising: a plurality ofphysical nodes, wherein an operating system is run collectively acrossthe plurality of physical nodes; wherein in response to receipt, at afirst physical node in the plurality, of a request from a secondphysical node in the plurality for a resource, a determination is madeat the first physical node whether to accept or deny the request for theresource, and wherein the request for the resource is associated with astalling event on the second physical node; wherein a response isprovided from the first physical node to the second physical node basedat least in part on the determination; and wherein the request for theresource is denied in the event that the resource has been or is beingtransferred to a third physical node in the plurality of physical nodes,and wherein the response provided to the second physical node includesan identifier of the third physical node to which the requested resourcehas been or is being transferred.
 2. The system recited in claim 1wherein the request for the resource is resent from the second physicalnode to the third physical node.
 3. The system recited in claim 1wherein the identifier comprises a forwarding address of the thirdphysical node.
 4. The system recited in claim 1 wherein a resource mapon the first physical node is updated with an indication that therequested resource has been or is being transferred to the thirdphysical node.
 5. The system recited in claim 1 wherein the request forthe resource is denied in the event that the resource is needed by thefirst physical node, and wherein the response comprises a messageindicating that the request for the resource has been denied.
 6. Thesystem recited in claim 5 wherein a determination is made at the secondphysical node that a virtual processor instantiated on the secondphysical node that is awaiting the requested resource should be migratedto the first physical node.
 7. The system recited in claim 6 wherein thedetermination to migrate the virtual processor is based at least in parton an evaluation of a cost function.
 8. The system recited in claim 7wherein evaluating the cost function includes determining whether anumber of times that the resource has been requested exceeds athreshold.
 9. The system recited in claim 1 wherein in the event thatthe request for the resource is accepted, the response comprises sendingthe requested resource to the second physical node.
 10. A method,comprising: receiving, at a first physical node in a plurality ofphysical nodes, a request from a second physical node in the pluralityfor a resource, wherein the request for the resource is associated witha stalling event on the second physical node; in response to receivingthe request, determining, at the first physical node, whether to acceptor deny the request for the resource; and providing a response from thefirst physical node to the second physical node based at least in parton the determination; wherein the request for the resource is denied inthe event that the resource has been or is being transferred to a thirdphysical node in the plurality of physical nodes, and wherein theresponse provided to the second physical node includes an identifier ofthe third physical node to which the requested resource has been or isbeing transferred; and wherein an operating system is run collectivelyacross the plurality of physical nodes.
 11. The method of claim 10wherein the request for the resource is resent from the second physicalnode to the third physical node.
 12. The method of claim 10 wherein theidentifier comprises a forwarding address of the third physical node.13. The method of claim 10 wherein a resource map on the first physicalnode is updated with an indication that the requested resource has beenor is being transferred to the third physical node.
 14. The method ofclaim 10 wherein the request for the resource is denied in the eventthat the resource is needed by the first physical node, and wherein theresponse comprises a message indicating that the request for theresource has been denied.
 15. The method of claim 14 wherein adetermination is made at the second physical node that a virtualprocessor instantiated on the second physical node that is awaiting therequested resource should be migrated to the first physical node. 16.The method of claim 15 wherein the determination to migrate the virtualprocessor is based at least in part on an evaluation of a cost function.17. The method of claim 16 wherein evaluating the cost function includesdetermining whether a number of times that the resource has beenrequested exceeds a threshold.
 18. The method of claim 10 wherein in theevent that the request for the resource is accepted, the responsecomprises sending the requested resource to the second physical node.19. A computer program product embodied in a non-transitory computerreadable storage medium and comprising computer instructions for:receiving, at a first physical node in a plurality of physical nodes, arequest from a second physical node in the plurality for a resource,wherein the request for the resource is associated with a stalling eventon the second physical node; in response to receiving the request,determining, at the first physical node, whether to accept or deny therequest for the resource; and providing a response from the firstphysical node to the second physical node based at least in part on thedetermination; wherein the request for the resource is denied in theevent that the resource has been or is being transferred to a thirdphysical node in the plurality of physical nodes, and wherein theresponse provided to the second physical node includes an identifier ofthe third physical node to which the requested resource has been or isbeing transferred; and wherein an operating system is run collectivelyacross the plurality of physical nodes.